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I hereby certify that this correspondence is being transmitted to the United States Patent & Trademark Office via electronic 
submission or facsimile on the date indicated below: 

08/03/2006 /Pamela Gerik/ 

Date Pamela Gerik 



SUPPLEMENTAL APPEAL BRIEF 

Sir/Madam: 

Further to the Notice of Appeal faxed August 24, 2004 and received in the U.S. Patent 
and Trademark Office on the same day. Appellant presents this Supplemental Appeal Brief 
This supplemental brief is filed in response to a Notice of Non-Compliant Brief mailed July 3, 
2006. The Notice of Appeal was filed following mailing of a Final Office Action on May 27, 
2004. Appellant hereby appeals to the Board of Patent Appeals and Interferences from a final 
rejection of claims 1-17 in the Final Office Action, and respectfully requests that this appeal be 
considered by the Board. 

1. REAL PARTY IN INTEREST 

The subject application is owned by International Business Machines Corporation, a 
corporation having its principal place of business at New Orchard Road, Armonk, New York, 
10504, as evidenced by the assignment recorded at 01 1888, Frame 0535. 
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II. 



RELATED APPEALS AND INTERFERENCES 



A Notice of Appeal has been filed for the following application, which shares a common 
specification with the application currently on appeal. 

09/870,615 Notice of Appeal filed 9/14/04 

09/870,62 1 Notice of Appeal filed 9/24/04 

However, because dissimilar art is cited in the present application and the above-mentioned 
related application. Appellants do not believe that the outcome of this appeal will have any 
bearing on the Board's decision on the related appeal. No other appeals or interferences are 
known which would directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 

III. STATUS OF CLAIMS 

Claims 1-17 are pending in the captioned case. Claims 1-17 stand rejected. 

IV. STATUS OF AMENDMENTS 

No amendments to the claims have been filed subsequent to their final rejection. The 
Appendix hereto therefore refiects the current state of the claims. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Appellant's claimed invention relates to a system of software components (82, 84 and 88, 
Fig. 8), a computer-readable storage device (18, Fig. 1) and a method (Figs. 8 and 10) for 
graphically displaying an object (object 24, Fig. 2) created by an application program (APP 28) 
running under, and at least somewhat dependent on, an operating system (OS 40). In accordance 
with aspects of the present invention, however, the object may be displayed in a manner that is 
truly independent from the operating system. (Specification - page 24, line 8 to page 29, line 10, 
and Abstract). 
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In some embodiments, the system of software components may be provided for 
graphically displaying an object (e.g., Button 30, Fig. 8) in a manner independent from the 
operating system. The system of software components may be stored, for example, in a 
computer-readable storage device. In one example, the system of software components may 
include a graphics resource component (e.g., JButton 48), a proxy component (e.g., JButton 
Proxy 88) and one or more peer components (e.g., JButton Peer 82 and/or JComponent Peer 84). 
The peer component may be adapted for receiving events pertaining to the object, and for routing 
the events to the proxy component. The proxy component may associate the object with the 
graphics resource component and invoke methods of the graphics resource component for 
displaying the object in a manner independent from the operating system. Because the graphics 
resource component does not use native code (i.e., OS-dependent code) for rendering images 
(e.g., image 26) of the object upon a display, the graphics resource component may be 
considered a "lightweight software component." (Specification - page 24, line 23 to page 27, 
line 14, and Fig. 8) 

In some cases, the presently claimed peer and proxy components may also be 
independent from the operating system. For example, the presently claimed peer component 
(e.g., JComponent Peer 84, Fig. 9) may be independent from the operating system (e.g., OS 40), 
but may be adapted to emulate the behavior of a second peer component (e.g.. Component Peer 
36), which does employ the windowing system of the operating system. In other words, the 
presently claimed peer component may be a "lightweight software component," which performs 
a function similar to the heavyweight version provided by the second peer component. Unlike 
the presently claimed peer component, however, the second peer component may contain native 
code (i.e., OS-dependent code), which may be used to invoke the graphical resources of the 
operating system (e.g., awt.dll 38) for creating an initial image (e.g., image 26) of the object 
(e.g.. Button 30) upon a display. (Specification - page 27, line 16 to page 28, line 8, and Fig. 9) 

In some cases, the object (e.g.. Button 30, Fig. 10) may be part of a graphical user 
interface (GUI). When the object is included within a particular layout (e.g.. Frame 41), the 
association of the object and the graphics resource component (e.g., JButton 48, Fig. 8) may 
enable a parent-child relationship to be established between the layout and the lightweight 
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graphics resource component. By establishing such a parent-child relationship, the presently 
claimed proxy component (e.g., JButton Proxy 88, Fig. 10) may allow the lightweight graphics 
resource component to draw an image of the object over the initial image of the heavyweight 
object, which was drawn with the aid of the windowing system of the operating system and the 
second peer component. By redirecting key events associated with the object (such as, e.g., 
focus, mouse, sizing, etc.) to the proxy component, the presently claimed peer component (e.g., 
JButton Peer 82) may enable the proxy component to respond to the key events, as if it were part 
of the layout containing the original heavyweight object. As a result, the presently claimed peer 
and proxy components may be used for displaying lightweight versions of the heavyweight 
objects originally included with the application program, while maintaining object functionality 
and without modifying the original apphcation program. (Specification - page 26, lines 7-14, 
page 28, line 10 to page 29, line 10, and Fig. 10) 

In some embodiments, the presently claimed method (Figs. 8 and 10) for graphically 
displaying an object (e.g.. Button 30) created by an application program running under an 
operating system (OS 40) may include the steps of: (i) utilizing a graphics resource component 
(e.g., JButton 48) adapted to display the object independently of the windowing system of the 
operating system, (ii) creating a proxy component (e.g., JButton proxy 88) and establishing an 
association between the object and the graphics resource component via the proxy component, 
(iii) receiving events pertaining to the object (e.g., focus, mouse, sizing, etc.) in a peer 
component (e.g., JButton peer 82) and routing them to the proxy component, and (iv) in response 
to the events, invoking methods of the graphics resource component via the proxy component to 
display the object. (Specification - page 25, line 1 to page 26, line 5, page 28, line 18 to page 
29, line 10, and Figs. 8 and 10) 

In some embodiments, the presently claimed computer-readable storage device (18, Fig. 
1) may include a windows-based operating system (OS 40, Figs. 1-2) and an application 

program (APP 28) running under the operating system. In addition, the computer-readable 
storage device may include a graphics resource component (e.g., JButton 48, Fig. 8) adapted to 
display an object (e.g.. Button 30), which was created by the application program independently 
of the windowing system of the operating system, by: (i) creating a proxy component (e.g.. 
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JButton proxy 88) and establishing an association between the object and the graphics resource 
component via the proxy component, (ii) receiving events pertaining to the object (e.g., focus, 
mouse, sizing, etc.) in a peer component (e.g., JButton peer 82) and routing them to the proxy 
component, and (iii) in response to the events, invoking methods of the graphics resource 
component via the proxy component to display the object. (Specification - page 25, line 1 to 
page 26, line 5, page 28, line 18 to page 29, line 10, and Figs. 1, 2, 8 and 10) 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1 . Claims 1-17 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over a web 
publication provided by Sun, entitled Introducing Swing (hereinafter "IS-SUN") in view 
of a web publication, entitled Mixing Heavy and Light Components, by Amy Fowler 
(hereinafter "M-SUN"). 

VII. ARGUMENT 

The contentions of the Appellant with respect to the ground of rejection presented for 
review, and the basis thereof, with citations of the statutes, regulations, authorities, and parts of 
the record relied upon are presented herein for consideration by the Board. Details as to why the 
rejections cannot be sustained are set forth below. 

A. Patentability of claims 1-6, 9-14 and 17 under 35 U.S.C $ 103(a) 

Independent claims 1, 9 and 17, and claims dependent thereon, were rejected as being 
unpatentable under 35 U.S.C. § 103(a) over a web publication provided by Sun, entitled 
Introducing Swing (hereinafter "IS-SUN") in view of another web publication, entitled Mixing 
Heavy and Light Components, by Amy Fowler (hereinafter "M-SUN"). 

MPEP 2143 establishes the basic requirements in finding a prima facie case of 
obviousness. As described, to establish a case of prima facie obviousness of a claimed 
invention, three criteria must be met. First, there must be some suggestion or motivation, either 
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in the references themselves or in the knowledge generally available to one of ordinary skill in 
the art to modify the references or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art references must teach or suggest all the 
claim limitations. Specifically, "all words in a claim must be considered when judging the 
patentability of that claim against the prior art." In re Wilson 424 F.2d. 1382, 1385 (CCPA 
1970). If an independent claim is nonobvious under 35 U.S.C. 103, then any claim depending 
therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). Using 
these standards. Applicants contend that the cited art fails to provide teaching, suggestion or 
motivation for all features of the currently pending claims, and furthermore, cannot be modified 
to do so. Several distinctive features of the present invention are set forth in more detail below. 

IS-SUN and M-SUN each fail to provide teaching or suggestion for a system (claim 
1), computer-readable storage device (claim 17), or method (claim 9) for graphical display 
of an object, where the system includes a peer component, which is adapted to receive 
events pertaining to the object and route the events to a proxy component, which associates 
the object with a graphics resource component and invokes methods thereof to display the 
object in a manner independent from an operating system. Independent claims 1, 9 and 17 
each recite limitations on a graphics resource component, a peer component and a proxy 
component. These components are included within a new system of software components, 
referred to as "AWTSwing". As described in more detail below, IS-SUN and M-SUN each fail 
to provide teaching or suggestion for the presently claimed peer and proxy components. 

The article entitled Introducing Swing does just as the title implies - it briefly outlines the 
Swing architecture and the basic differences between Swing and AWT. However, Introducing 
Swing (otherwise referred to as IS-SUN) does not provide teaching or suggestion for a system, 
computer-readable storage device, or method for graphical display of an object, where the 
system comprises a peer component, which is adapted to receive events pertaining to the object 
and route the events to a proxy component, which associates the object with a graphic resource 
component and invokes methods thereof to display the object in a manner independent from an 
operating system, as taught in present claims 1, 9, and 17. 
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Statements in the Office Action mailed November 21, 2003 and in the final Office Action 
mailed May 27, 2004 admit that IS-SUN fails to provide teaching or suggestion for the presently 
claimed peer and proxy components. For example, the Examiner clearly states, "IS-SUN . . . 
doesn't teach a proxy component which associates the object with the graphics resource 
component and invokes methods of the graphics resource component to display the object, or a 
peer component, adapted to receive events pertaining to the object and route the events to the 
proxy." (See, Office Action, page 2, Final Office Action, pages 2-3). Appellants sincerely 
appreciate the Examiner's recognition of the lack of teaching within IS-SUN for the peer and 
proxy components recited in present claims 1, 9, and 17. 

Though the Examiner admits to the lack of teaching within IS-SUN for the presently 
claimed peer and proxy components, the Examiner suggests that such teaching can be found 
within the article entitled Mxmg heavy and light components (otherwise referred to as M-SUN). 
For example, the Examiner states, "M-SUN teaches a method of implementing swing 
components similar to that of IS-SUN, but further teaches a proxy component that associates an 
object with a graphics resource component, and further displays the object, in that the proxy 
component is the swing class (see page 2, paragraph 2), and a peer component, adapted to 
receive events pertaining to the object and route the events to the proxy component, in that the 
peer component is the ancestor (see page 2, paragraph 2)." (See, Office Action, page 2; final 
Office Action, page 3). In addition, the Examiner suggests that "it would have been obvious to 
one of ordinary skill in the art. . . to modify the swing component interface of IS-SUN to include 
the combinational properties as did M-SUN." (Office Action, page 3, Final Office Action, page 
3). The Appellants respectfully disagree with the Examiner's interpretation of peer and proxy 
components, for at least the reasons set forth in more detail below. 

M-SUN cannot be combined with IS-SUN to overcome the deficiencies therein, because 
like IS-SUN, M-SUN fails to provide teaching or suggestion for the presently claimed peer and 
proxy components. Instead, M-SUN discloses various problems that may arise when 
programmers attempt to mix heavyweight AWT components with lightweight Swing 
components. Some of the problems disclosed by M-SUN are similar to those disclosed in the 
present specification. For example, M-SUN mentions some of the difficulties encountered when 
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one attempts to add lightweight Swing components to an AWT layout by "painting" or 
"drawing" images of the Swing components over pre-existing AWT images. On page 3, M-SUN 
states that "[w]hen a hghtweight component overlaps a heavyweight component, the 
heavyweight component is always on top, regardless of the relative z-order of the two 
components." On page 4, M-SUN illustrates how images rendered by heavyweight AWT 
components will obscure any overlapping images rendered by lightweight Swing components, 
and explicitly states that a "Swing label will never appear to be on top of [an] AWT label 
because the Swing label is rendering its contents in the native window of the frame (its first 
heavyweight ancestor), while the AWT label is rendering its contents in its own native window, 
which is actually a child of the frame's native window." As such, M-SUN recognizes a 
fundamental limitation of Swing, which does not permit images of Swing components to be 
drawn over AWT renderings . 

The presently claimed case provides a solution to the above-mentioned problem by 
creating a proxy component, which is not included within the existing classes of software 
components belonging to the Swing application program interface (API). The presently claimed 
proxy component enables Swing components to be successfully incorporated within AWT-based 
application programs by associating the existing heavyweight (AWT) objects with lightweight 
(Swing) graphics resource components. This enables the proxy component to invoke the 
methods of the lightweight graphics resource components for displaying objects independently 
from the operating system. The presently claimed peer component differs from typical Swing 
peer components by routing events intended for the existing heavyweight object to the presently 
claimed proxy component . See, Specification, page 24, line 8 - page 29, line 10. 

Unlike the presently claimed case, M-SUN provides no solution to the problem other 
than sheer avoidance. For example, M-SUN states, "[bjecause there's sometimes no alternative 
to mixing heavyweight and lightweight components, we have provided a few options in Swing to 
make a certain level of component-mixing possible." (M-SUN, page 3, paragraph 2). These 
options, or guidelines, include: "[d]o not mix lightweight (Swing) and heavyweight (AWT) 
components within a container where the lightweight component is expected to overlap the 
heavyweight one." (M-SUN, page 5). From the above guideline, it is obvious that M-SUN 
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chooses to avoid problematic situations, rather than present solutions to the problem. Since M- 
SUN fails to provide any solution of his own, M-SUN cannot be relied upon to disclose the 
presently claimed solution. In other words, M-SUN simply fails to provide any teaching or 
suggestion for the peer and proxy components recited in claims 1, 9, and 17. 

In light of the Examiner's suggestion that "the proxy component [of M-SUN] is the 
swing class" and "the peer component [of M-SUN] is the ancestor," the Appellants wish to 
clarify the terms "class" and "ancestor" as they are used in the context of object-oriented 
programming and the presently claimed case. As described on pages 4 and 5 of the 
specification, a "class" is a fundamental entity in an object-oriented programming language that 
possesses certain attributes (e.g., shape, color, size, location on screen, behavior, etc.), which are 
common to all "objects" belonging to the class. The objects can be developed as modular 
building blocks, with subsequent objects referred to as "children" of higher-level "parent" 
objects. In some cases, a parent object may be a "class" of child objects, and the child objects 
may inherit the class attributes (i.e., the properties and methods) of the parent object, or 
"ancestor", from which they derive. In the embodiment of Fig. 8, for example. Component 32 
may be considered a "class" of objects, where one of the objects in the class is Button 30. 
Component 32 may also be considered to be a "parent" or "ancestor" of Button 30, since various 
methods and/or properties of Button 30 may be derived from Component 32. 

However, a "Swing class" cannot be considered to be a "proxy componenf as suggested 
by the Examiner, since a "Swing class" merely defines the properties and methods (e.g., shape, 
color, size, location on screen, behavior, etc.) of a collection of Swing objects, whereas a "proxy 
component" actually functions to associate an object (e.g., a button displayed in a GUI) with a 
graphics resource component (e.g., JButton 48) and to invoke the methods of the graphics 
resource component (e.g., run the program code contained within JButton 48) for displaying the 
object . A "Swing class," in itself, does not and cannot function to associate an object with a 
graphics resource component, invoke the methods of the graphics resource component, or 
display the object. Therefore, the mere mention of Swing classes within M-SUN does not 
provide teaching or suggestion for the proxy component recited in present claims 1, 9, and 17. 
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Furthermore, though a "peer component" may be an "ancestor" of some other object, 
merely stating so provides no evidence of the peer component being adapted to receive events 
pertaining to the object and to route the events to a proxy component . Since M-SUN fails to 
provide teaching for a "proxy component", any peer components that may be described by M- 
SUN cannot be configured to route events to a non-existent proxy component. As such, M-SUN 
also fails to provide teaching or suggestion for the peer component recited in present claims 1 , 9, 
and 17. 

The above arguments were presented in a Response to the Office Action mailed 
November 21, 2003. After reviewing the above arguments, the Examiner maintained his 
position in the final Office Action by providing yet another interpretation of the term "proxy 
component." For example, statements in the final Office Action suggest that "the swing class [of 
M-SUN] can be considered a proxy component in the sense that a proxy can mean an element 
that acts as a substitute for another element (swing for AWT)." (Final Office Action, page 7). As 
described in more detail below, the Appellants disagree with the Examiner's latest interpretation 
of a "proxy component," and further assert that a "Swing class" cannot be considered a "proxy 
component," as it is defined by the presently claimed case . 

The Appellants recognize that, "[djuring examination, the claims must be interpreted as 
broadly as their terms reasonably allow.'" (See, MPEP 21 1 1.01). However, the Appellants assert 
that the pending claims cannot be interpreted more broadly than their terms reasonably allow, or 
be given a meaning that is inconsistent with the specification. The specification and present 
claims 1, 9 and 17 each describe the presently claimed "proxy component" as one that associates 
an object with a graphics resource component and invokes methods of the graphics resource 
component to display the object. Even when given its plain meaning, it is simply unreasonable 
for one skilled in the art to interpret the term "proxy component" as "an element that acts as a 
substitute for another elemenf since neither the specification nor the claims support such an 
interpretation. As such, the Examiner's interpretation of the term "proxy component" is 
considered to be improper and erroneous. 
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In addition, the mere mention of Swing classes within M-SUN cannot be relied upon to 
provide teaching or suggestion for a proxy component, regardless of the manner in which the 
term "proxy componenf is interpreted. As noted above, a "Swing class" merely defines the 
common properties and methods (e.g., shape, color, size, location on screen, behavior, etc.) 
associated with a collection of Swing objects that descend from the Swing class. However, a 
"Swing class" does not function to associate an object with a graphics resource component, nor 
does a "Swing class" invoke methods of the graphics resource component for displaying the 
object. Therefore, the mere mention of Swing classes with M-SUN does not provide evidentiary 
support for the presently claimed "proxy component", as it is defined by the specification and the 
present claims . Furthermore, and contrary to the Examiner's suggestions in the final Office 
Action, Swing classes are not "elements that act as substitutes for other elements," and more 
specifically, do not substitute Swing components for AWT components. Therefore, a "Swing 
class" cannot be considered equivalent to a "proxy component," even as it is improperly defined 
by the Examiner . 

Further statements in the final Office Action appear to suggest that the presently claimed 
proxy component may be inherently taught by M-SUN. For example, the Examiner suggests 
that since M-SUN "teaches a combination of two APIs ... in order to combine two APIs there 
must be a connecting element." (Final Office Action, page 7). Again, Appellants assert that it is 
improper to oversimplify and loosely interpret the presently claimed proxy component as a 
"connecting element," since such interpretation is significantly more broad than allowed by the 
language used in claims 1, 9, and 17. Therefore, Appellants maintain the assertion that 
absolutely no teaching or suggestion for the presently claimed proxy component can be found, 
either explicitly or inherently described, within the sole reference (M-SUN) which the Examiner 
relies upon to provide such teaching. 

There is no motivation to combine or modify the teachings of IS-SUN and M-SUN to 
provide the presently claimed peer and proxy components. As explained above, IS-SUN and 
M-SUN each fail to provide teaching or suggestion for the presently claimed peer and proxy 
components, and therefore, cannot be combined to do so. Even if the cited art were improperly 
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combined, the combined cited art would still fail to provide teaching or suggestion for the peer 
and proxy components described in present claims 1, 9, and 17. 

In addition, the cited art cannot be modified to teach or suggest the aforementioned 
limitation, since IS-SUN and M-SUN each fail to suggest a desirability for doing so. The mere 
fact that references can be combined or modified does not render the resultant combination 
obvious unless the prior art also suggests the desirability of the combination [or modification]. 
In re Mills, 916 F.2d 680, 16 USPQ2d 1430 (Fed. Cir. 1990); MPEP 2143.01. 

Unlike the presently claimed case, IS-SUN fails to mention the difficulties involved in 
mixing heavyweight AWT components and lightweight Swing components. Consequently, IS- 
SUN provides no desirability for overcoming such difficulties by providing lightweight peer and 
proxy components, as described in claims 1, 9 and 17. Though M-SUN does admit to some 
difficulties in mixing heavyweight AWT components and lightweight Swing components, M- 
SUN chooses to deal with the difficulties by avoiding the problematic situations altogether. By 
choosing avoidance, M-SUN fails to provide motivation for a system or method that actually 
solves the problem. Since IS-SUN and M-SUN each fail to provide motivation to teach or 
suggest the aforementioned limitations of the presently claimed case, IS-SUN and M-SUN 
cannot be modified to do so. 

Obviousness can only be established by combining or modifying the teachings of the 
prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed.Cir. 1988); In re Jones, 
958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992); MPEP 2143.01. Appellants assert that the 
teaching or suggestion to make the claimed combination [or modification] must be found in the 
prior art, and not based on Applicant's own disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 
1438 (Fed. Cir. 1991); MPEP 2142. 
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B. 



Patentability of claims 7, 8, 15 and 16 under 35 U.S.C $ 103(a) 



Claims 7-8 and 15-16 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
IS-SUN in view of M-SUN. Because claims 7-8 and 15-16 are dependent from independent 
claims 1 and 9, respectively, the arguments presented above for patentability of claims 1 and 9 
apply equally to claims 7-8 and 15-16, and are herein incorporated by reference. In addition to 
the § 103 arguments presented above with respect to claims 1 and 9, additional arguments are 
provided below to establish patentability of dependent claims 7-8 and 15-16. 

None of the cited art teaches or suggests that, when the object is part of a layout, the 
association of the object with the graphics resource component can be used to establish a 
parent-child relationship between the layout and the graphics resource component, which 
can then be used to allow the lightweight graphics resource component to draw over an 
existing image of the object drawn with the aid of the windowing system of the operating 
system. Claims 7-8 and 15-16 place a further limitation on the presently claimed proxy 
component. For example, claims 7-8 and 15-16 state that when the object is part of a layout, the 
association of the object with the graphics resource component establishes a parent-child 
relationship between the layout and the graphics resource component, which allows the graphics 
resource component to draw over an existing image of the object drawn with the aid of the 
windowing system of the operating system. As such, claims 7-8 and 15-16 place additional 
limitations on the proxy component introduced in claims 1 and 9, respectively, by describing 
how the proxy components may establish a parent-child relationship, which allows lightweight 
(i.e.. Swing) graphics resource components to "draw" or "paint" over existing images of 
heavyweight (i.e., AWT) objects drawn with the graphical resources of the operating system. 

As noted above, IS-SUN and M-SUN each fail to disclose the presently claimed peer and 
proxy components, and furthermore, cannot be modified or combined to do so. As described in 
more detail below, IS-SUN and M-SUN also fail to provide teaching or suggestion for the 
additional limitations placed on the presently claimed proxy component, as set forth in 
dependent claims 7, 8, 15, and 16. 
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Statements in the final Office Action rely on M-SUN for teaching the limitations of 
dependent claims 7, 8, 15, and 16. For example, the final Office Action states, "M-SUN teaches, 
in page 4, paragraph 2 and page 6, paragraph 2 and the following picture, that if heavyweight 
components are used it is possible for them to obscure what is drawn by the windowing system 
of the operating system." (Final Office Action, page 5). The Appellant agrees with the 
Examiner's current interpretation of M-SUN. Heavyweight (AWT) components included within 
prior art legacy applications will, in fact, obscure any lightweight (Swing) components, which 
are purposefully or inadvertently placed underneath the heavyweight components. For example, 
M-SUN illustrates the case in which a heavyweight label is drawn on top of a lightweight label 
on page 4. 

However, the Examiner's current interpretation is completely inconsistent with the 
limitations recited in dependent claims 7, 8, 15, and 16, which describe how a parent-child 
relationship may allow a lightweight graphics resource component (see, claims 1 and 9) to draw 
over an existing image of a (heavyweight) object drawn with the aid of the operating system . 
Because M-SUN clearly states that lightweight Swing objects "will never appear to be on top" of 
heavyweight AWT objects (see, pages 3-4 of M-SUN), M-SUN cannot be relied upon to provide 
teaching or suggestion for the additional limitations set forth in dependent claims 7, 8, 15, and 
16. 

There is no motivation to modify or combine the cited art to teach or suggest the 
presently claimed parent-child relationship. As noted above, none of the cited art provides 
teaching or suggestion for the presently claimed parent-child relationship, which allows a 
(lightweight) graphics resource component to draw over an existing image of a (heavyweight) 
object drawn with the aid of the operating system, as described in claims 7-8 and 15-16. 

In addition to the lack of teaching. Appellants assert that the cited art cannot be combined 
or modified to teach or suggest the presently claimed parent-child relationship, since the cited art 
fails to suggest a desirability for doing so. The mere fact that references can be combined or 
modified does not render the resultant combination obvious unless the prior art also suggests the 
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desirability of the combination. In re Mills, 916 F.2d 680, 16 USPQ2d 1430 (Fed. Cir. 1990); 
MPEP 2143.01. 

As noted above, M-SUN fails to provide a manner in which lightweight graphics 
resource components can be used to successfully draw over images previously drawn with the 
aid of the operating system. Instead, M-SUN strongly recommends that programmers "[d]o not 
mix lightweight (Swing) and heavyweight (AWT) components within a container where the 
lightweight component is expected to overlay the heavyweight one." (M-SUN, page 4, paragraph 
3). By choosing avoidance, rather than presenting a solution to the problem, M-SUN provides 
no desirability for the presently claimed parent-child relationship. As such, M-SUN cannot be 
modified to teach or suggest the additional limitations set forth in dependent claims 7, 8, 15, and 
16. 

For at least the foregoing reasons. Appellant asserts that independent claims 1, 9, and 17, 
as well as claims dependent therefrom, are patentably distinct over IS-SUN and M-SUN. 
Contrary to the characterizations made in the various Office Actions, the cited references cannot 
be properly combined or modified to provide teaching for all limitations recited in claims 1, 9, 
and 17. Accordingly, Appellants assert that a prima facie case of obviousness has not been duly 
set out and, therefore, request that this rejection be reversed. 



For the foregoing reasons, it is submitted that the Examiner's rejection of claims 1-17 
was erroneous, and reversal of the decision is respectfully requested. 

The Commissioner is authorized to charge the required fees to Daffer McDaniel LLP 
deposit account number 50-3268/5468-07300. 
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Respectfully submitted, 
/Kevin L. Daffer/ 
Kevin L. Daffer 
Reg. No. 34,146 
Attorney for Appellant 

Customer No. 35617 
Date: August 3. 2006 

JMF 
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VIII. CLAIMS APPENDIX 



The present claims on appeal are as follows. 

1 . A system for graphical display of an object created by an application program running 
under an operating system, comprising: 

a graphics resource component adapted to display the object independently of the 
operating system; 

a proxy component, which associates the object with the graphics resource component 
and invokes methods of the graphics resource component to display the object; 
and 

a peer component, adapted to receive events pertaining to the object and route the events 
to the proxy component. 

2. The system as recited in claim 1 , wherein the peer component is independent of the 
operating system, and emulates the behavior of a second peer component that employs the 
windowing system of the operating system. 

3. The system as recited in claim 1, wherein the object is part of a graphical user interface 
(GUI) associated with the application program. 

4. The system as recited in claim 3, wherein a look and feel of the GUI is independent of the 
operating system. 

5. The system as recited in claim 1, wherein the application program is written in Java 
programming language. 
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6. The system as recited in claim 1, wherein the proxy extends an existing class of software 
components belonging to the Swing application program interface (API). 

7. The system as recited in claim 1 , wherein the object is part of a layout, and the 
association of the object with the graphics resource component establishes a parent-child 
relationship between the layout and the graphics resource component. 

8. The system as recited in claim 7, wherein the parent-child relationship between the layout 
containing the object and the graphics resource component allows the graphics resource 
component to draw over an existing image of the object drawn with the aid of the windowing 
system of the operating system. 

9. A method for graphical display of an object created by an application program running 
under an operating system, comprising: 

utilizing a graphics resource component adapted to display the object independently of 
the windowing system of the operating system; 

creating a proxy component and establishing an association between the object and the 
graphics resource component via the proxy component; 

receiving events pertaining to the object in a peer component and routing them to the 
proxy component; and 

in response to the events, invoking methods of the graphics resource component via the 
proxy component to display the object. 

10. The method as recited in claim 9, wherein the peer component is independent of the 
operating system, and the method further comprises emulating the behavior of a second peer 
component that employs the windowing system of the operating system. 
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1 1 . The method as recited in claim 9, wherein the object is part of a graphical user interface 
(GUI) associated with the application program. 

12. The method as recited in claim 1 1 , wherein a look and feel of the GUI is independent of 
the operating system. 

13. The method as recited in claim 9, wherein the application program is written in Java 
programming language. 

14. The method as recited in claim 9, wherein the proxy extends an existing class of software 
components belonging to the Swing API. 

15. The method as recited in claim 9, wherein the object is part of a layout, and the method 
further comprises using the association of the object with the graphics resource component to 
establish a parent-child relationship between the layout and the graphics resource component. 

16. The method as recited in claim 15, further comprising using the parent-child relationship 
between the layout containing the object and the graphics resource component to allow the 
graphics resource component to draw over an existing image of the object drawn with the aid of 
the windowing system of the operating system. 

17. A computer-readable storage device, comprising: 
a windows-based operating system; 

an application program running under the operating system; 

a graphics resource component adapted to display an object created by the application 
program independently of the windowing system of the operating system, by: 
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creating a proxy component and establishing an association between the object 
and the graphics resource component via the proxy component; 

receiving events pertaining to the object in a peer component and routing them to 
the proxy component; and 

in response to the events, invoking methods of the graphics resource component 
via the proxy component to display the object. 
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IX. EVIDENCE APPENDIX 

No evidence has been entered during the prosecution of the captioned case. 
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X. RELATED PROCEEDINGS APPENDIX 



A Notice of Appeal has been filed for the following application, which shares a common 
specification with the application currently on appeal. 

09/870,615 Notice of Appeal filed 9/14/04 

09/870,62 1 Notice of Appeal filed 9/24/04 

However, because dissimilar art is cited in the present application and the above-mentioned 
related application. Appellants do not believe that the outcome of this appeal will have any 
bearing on the Board's decision on the related appeal. No other appeals or interferences are 
known which would directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 
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